[レポート][PwCコンサルティング合同会社] PwCが提供する製品セキュリティテストの流れと実施ポイント – CODE BLUE 2023 #codeblue_jp

CODE BLUE 2023で行われた「[PwCコンサルティング合同会社] PwCが提供する製品セキュリティテストの流れと実施ポイント」というセッションのレポートです。

#CODE BLUE

#CODE BLUE 2023

#セキュリティ

江口佳記

2023.11.08

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

CODE BLUE 2023で行われた以下のセッションのレポートです。

[PwCコンサルティング合同会社] PwCが提供する製品セキュリティテストの流れと実施ポイント

近年の製品セキュリティ領域では、法規制などに伴い、メーカーだけでなくサプライチェーン全体でセキュアな製品づくりが求められています。セキュリティ品質の高い製品は、PSIRTをはじめとしたリリース後の保守・運用フェーズにおける負荷軽減にもつながります。セキュリティ品質を保証するためには、ソフトウェア品質同様にテストが効果的であり、前述の法規制などに伴い、これからセキュリティテストを実施するメーカーやサプライヤーが増えることが見込まれます。またサプライヤーにおいては、今現在は不要だったとしても、今後取り扱う製品（部品）によっては、メーカー側からセキュリティテストが求められる可能性があります。本講演では、PwCコンサルティング合同会社がこれまでに提供してきたテスト実績に基づいた、製品セキュリティテストを実施する際の流れと考慮すべきポイントについて解説します。

Presented by : 和栗直英 (シニアマネジャー)

レポート

講演者（和栗氏）について
- PSIRTなど、製品領域に専門性があり情報発信をしている
製品セキュリティに関するサイバー攻撃の動向
- IoT機器へのサイバー攻撃、マルウェアが増加
- 誰でも高度な攻撃ができるように
製造業に対するセキュリティ対応要求が高まっている
- IoTセキュリティに関する国際標準の規定など
- 各国の法規制
製品セキュリティ問題に対するメーカー責任
- メーカーは法規制や訴訟に対応していかなければならない
サプライチェーンリスクが増大している
こうした背景から製品セキュリティの必要性が高まっている
製品セキュリティ品質確保活動の継続的な高度化・効率化が必要
- 効率化の例：シフトレフト、DevSecOps、バグバウンティの積極的実施、法令遵守・責任範囲の明確化
PwCが提供するセキュリティテストについて
- 脆弱性テストとペネトレーションテストの違い
  - 脆弱性テストは脆弱性を洗い出すことが目的。診断項目ベース。実施主体は開発者もしくは第三者
    - 診断が項目ベースのため。将来的に内製化も可能
  - ペネトレーションテストは攻撃社視点で侵入を試みセキュリティ対策の妥当性を評価する。脅威シナリオベース。実施主体は製品開発に携わらない第三者
    - ブラックボックスでのテストが基本のため、基本的には外部の第三者に実施してもらう
- 脆弱性テスト概要
  - ヒアリング・診断項目選定 -> 診断 -> 診断結果評価・報告
    - 期間が予測しやすい
- ペネトレーションテスト概要
  - テストシナリオ策定 -> テスト計画の策定 -> テストの実施・レポート
    - アプローチ例：
      - ハードウェア基本調査 -> ハードウェア詳細調査 -> アーキテクチャ分析 -> ソースコード分析 -> 攻撃可能性分析 -> PoC（攻撃コード）の作成
        
        PoCは場合によってやらない場合もある
- セキュリティテストを実施する上でのポイント
  - どこまでやっても100%防御可能とするのは難しく、どこまでテストすれば問題ないといえるのかが難しい
  - ペネトレーションテストの場合
    - 誰がどの単位で実施するべきか
    - どの製品に対してテストが必要なのか
    - 開発スケジュールに合わせて時間が十分取れるか
  - 脆弱性テスト
    - ツールを買う必要はあるか
    - ファジングはどこまでやる必要があるか、テストケースはどう選定すればよいか
    - 対象とすべき機能は？
    - どこまで厳密に結果をレビューすべきか？
  - テストを実行する際には、関連する仕様情報や周辺の環境をどこまで提供できるかを事前調整しておくことが望ましい
    - すべて必要とは限らないため、当初は必要最低限の情報のみを提供し、テスト状況を鑑みて段階的に開示していくことが一般的
    - ファームウェアの抽出を目的としてテストを行った場合、抽出ができなかった場合にそこでテストを終了するか？それともファームウェアが今後別の方法で抽出されることを前提にテストをするか？なども考える
  - ハードウェア解析
    - ファームウェアの入手を目的としてハードウェアの耐久性を評価する（分解してファームウェアを抽出されるか）
  - ソフトウェア解析
    - バイナリ解析を通じて機密情報の取り扱いや入力データ処理の実装などの確認を行う
  - ファジング/既知脆弱性スキャン
    - ファジング
      - ファジングツールにより不正なデータ・予期しないデータを送信、意図的な例外を発生され潜在的な脆弱性を露出させる
    - 既知脆弱性スキャン
      - OSSのライブラリやOSに対して既知脆弱性がないかを網羅的にチェック
  - デザイン/ソースコードレビュー
    - デザインレビュー
      - コードの設計書や実際のコードを確認し処理の方法や構造などに問題ないかを確認
    - ソースコードレビュー
  - セキュリティテストの難しさ
    - 実機環境
      - IoT機器の場合、テスター側がサーバーとしてふるまう必要がある
      - クライアント製品のテストの場合、自動化の難易度が高い
    - 非実機環境
      - 自動化されることが前提のため工数負担が大きい
      - 開発環境、各種ツールを理解しているエンジニアが必要
  - 攻撃者の属性とモチベーションの違い（車での例）
    - 攻撃者は組織か、一利用者か
      - 組織的の場合
        
        車両を盗難する
        
        チューナーとしてコーディングなどにより利用者へ技術料をもらってマネタイズする
      - 利用者の場合
        
        オーナーが非公式機能を実現する
        
        研究者が調査・研究目的で自動運転キットなどを実装する
    - 製品に対する攻撃者の属性からモチベーションを考察することができ、テスト計画の参考になる
  - 製品特有のテスト手法と課題
    - 製品特有のテストにフォルトインジェクション（グリッチ）と呼ばれる手法があり、発表事例が増えている
    - デバイスに生じる短期間の障害
    - 一般的な脅威と比べて対策が難しいのが課題